Let maintainers know that an action is required on their side

• Add the label release-required Please cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module) when you request a maintainer to cut a new release (Devolutions Gateway, Devolutions Agent, Jetsocat, PowerShell module)

• Add the label release-blocker Follow-up is required before cutting a new release if a follow-up is required before cutting a new release

• Add the label publish-required Please publish libraries (`Devolutions.Gateway.Utils`, OpenAPI clients, etc) when you request a maintainer to publish libraries (Devolutions.Gateway.Utils, OpenAPI clients, etc.)

• Add the label publish-blocker Follow-up is required before publishing libraries if a follow-up is required before publishing libraries

Implementation notes (audit findings for DGW-436):

Verified as already correct (SYSTEM/service mode) — execute_as_system in devolutions-agent/src/broker/executor/windows/mod.rs:

• Obtains the client user's real session token via WTSQueryUserToken (matched by SID, not name), duplicates it as primary, and assigns the session ID before CreateProcessAsUserW.
• Loads the environment block from that token, so %LOCALAPPDATA%, %USERPROFILE%, and HKCU resolve to the actual client user — per-user scope installs land in the right profile.
• Processes are created on WinSta0\Default in the user's session, so --interactive installer UIs are visible on the user's desktop, never stuck in session 0.
• No active logon session for the user → the operation fails with a clear error instead of installing into the SYSTEM profile (error message clarified in this PR).

Gap fixed (non-SYSTEM mode) — the execution path is selected at runtime by checking whether the process token is LocalSystem, not by a cargo feature; a release binary launched as a regular user takes the same path. There, execute_as_current_user ignored ctx.user_sid and ran everything under the broker process token. Since the pipe DACL grants BUILTIN\Users connect access, a client running as a different user would get its user-scope install written into the broker user's profile. The executor now compares the authenticated pipe client SID against the broker process token SID and rejects mismatches.

Why not a capability flag: ManagerCapability in now-policy-api 0.2 has no interactive/user-scope execution field to gate on, and interactive mode is already gated per-manager (builders reject it where unsupported) and per-policy (AllowInteractive). The remaining gap was an executor identity check, addressed here.

Testing: new unit test non_system_mode_rejects_client_user_different_from_broker_user (uses the Everyone SID, which never matches the test process user). Existing SYSTEM-mode behavior is covered by the ignored psexec -s test. cargo clippy --tests -D warnings clean.